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TRANSACTIONAL COMPUTER SYSTEM 



BACKGROUND OF THE INVENTION 

This invention relates to a transactional computer 
system, namely a computer system adapted to perform 
5 negotiation and decision making functions related to a 
transaction . 

Transactional computer systems are known for use in 
the financial and business world for conducting 
transactions such as, for example, ordering product, 
10 currency exchange, or the sale and purchase of stock, 

shares and bonds. Such systems are designed specifically 
for the particular function or functions which they are to 
perform. 

Rule-based systems using what is generally known as 
15 artificial intelligence are also known. These are based 
on a large number of rules which are specific to the 
particular environment in which they are to be used. A 
given system is designed for a particular type of 
transaction, and if a new type of transaction is envisaged 
20 a new system will have to be designed specifically for 

that purpose. 

We have appreciated that it would be highly desirable 
to provide a generalised transactional system which can be 
adapted to many specific types of transaction, and 
25 furthermore we have appreciated that such a generalised- 

transactional computer system can be made by using the 
ideas and features described in the following and claimed 
in the claims appended to this description. 
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SUMMARY OF THE INVENTION 

The invention is defined in the independent claims 
below to which reference should now be made. Advantageous 
features are set forth in the appendant claims. 

According to the present invention there is provided 
a transactional computer system comprising a plurality of 
entities including at least one entity of each of the 
following forms, a first entity (Thing entity) having the 
properties of identifying a client system and uniquely 
identifying an object in that client system, a second 
entity (Proposal entity) for defining a transaction, the 
second entity being subordinate directly or indirectly to 
a first entity and having the properties of modelling at 
least one external agent to carry out a transformation in 
relation to the first entity, and a third entity (Decision 
entity) capable of communicating with a second entity and 
having the properties of defining the types of decision 
that may be made, and determining the responses in 
relation to those decisions. 

Preferably the computer system further comprises at 
least one fourth entity (Assignment entity) subordinate to 
an associated first entity, the fourth entity having the 
properties of uniquely identifying the associated first 
entity, and identifying a particular type of assignment or 
transf oirmation to be applied to the first entity. This 
entity may be combined with the second entity. 

Additionally the computer system preferably further 
comprises at least one further entity (Tender entity) 
associated with a plurality of second entities and a 
single first entity, and identifying at least a quantity. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will now be described in more detail by 
way of example, with reference to the drawings, in which: 

Figure 1 illustrates the heirarchical structure of 
5 the entities in a preferred computer system embodying the 
invention; 

Figure 2 is a flow chart illustrating the NewEntity 

procedure in the preferred embodiment of the inventions- 
Figure 3 is a flow chart illustrating the 
10 RegisterEntity procedure in the preferred embodiment of 

the invention; 

Figure 4 is a flow chart illustrating the 

LoadHierarchy procedure in the preferred embodiment of the 

invention; 

15 Figure 5 is a flow chart illustrating the Math: 

AddDecision procedure in the preferred embodiment of the 
invention; 

Figure 6 is a flow chart illustrating the Cube: Apply 
Decision procedure in the preferred embodiment of the 
20 invention; 

Figure 7 is a flow chart illustrating the 
Item (EntityKey ) procedure in the preferred embodiment of 
the invention; 

Figure 8 is a flow chart illustrating the Math: 
25 GetMathValue procedure in the preferred embodiment of the 
invention; and 

Figure 9 is a flow chart illustrating the Cube: 
GetValue procedure in the preferred embodiment of the 
invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

GENERAL DESCRIPTION 
This system is embodied in a computer software module 
which/ when included in a client system, will capture the 
5 complexity of its negotiations, but leave the description 
of those transactions to the client system. The system 
makes possible the management of the transaction space in 
a straightforward and effective manner. It does not, 
however, manage the transaction space directly. Rather, 

10 it supports the modelling of the transaction space in a 

convenient and effective manner, and then, once modelled, 
it is for the client system to respond to the situations 
discerned and captured in the model. The power of the 
system is in its flexibility for modelling and managing 

15 the client system's complex transaction space. 

The system will only capture and supply information 
without using it for its own internal manipulation. It is 
better to record what people claim, and then leave the 
external clients/parties to resolve their claims, than it 

20 is to try to decide the truth of a matter. Consequently, 
the validity or otherwise of the supplied information has 
no bearing on the system. However, it may have a 
significant bearing on the satisfactory use of the system; 
therefore the client system should validate the 

25 information supplied and act accordingly. 

The system comprises a hierarchy of entities: a 
Thing, a Proposal and a Decision, and optionally an 
Assignment and/or a Tender. Each entity type has a set of 
properties appropriate to its role. These are described 

30 in more detail below as part of the preferred embodiment. 
It is a feature of the system that an extension of the 
modelling environment can be achieved by the provision of 
additional properties per entity. 
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THE THING ENTITY 
The system supports the modelling of the existence of 
external objects by provision of a 'Thing' entity. In the 
preferred embodiment, the Thing entity has fields 
5 ClientSystem, and ClientSystemRef erence . The ClientSystem 
field is an identifier of the client system itself, and 
the ClientSystemRef erence field is an identifier by which 
the implicit existence of an object identified by that 
Reference is posited. 
10 No validation as to the nature of that implicit 

object is either attempted or warranted, nor of any other 
information pertaining to the world outside the system. 

A ClientSystemRef erence to a Thing must be unique, so 
that all behaviours and data to a common external thing 
15 will be mapped and managed by a common internal Thing. 

Client applications must ensure that they have implemented 
an appropriate nomenclature to ensure unique references 
per client system. 

THE ASSIGNMENT ENTITY 
The system supports the modelling of assignments or 
transformations applied to external objects. It does so 
by provision of an 'Assignment' entity. An Assignment, 
for the purposes of the system, is regarded as a 
transformation that may be applied to a Thing, for example 
an operation which can be conducted in relation to an 
object. Thus, in the system's entity hierarchy, an 
Assignment is subordinate to and applies to a Thing . 

An Assignment will comprise in particular an 
identifier for the particular type of assignment or 
transformation to be applied. This key information is 
supplied by the external client system in the Assignment's 
'Redirection' field, see below. 

Timing of an assignment will often be significant to 
the external client. A facility to recognise timing may, 
if desired, be provided by the inclusion of fields 
appropriate to each of the distinct entity types. In 



25 



30 
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particular, fields relating to overall deadlines for 
Assignments may be included in that entity. 

LINKING ASSIGNMENTS 
The system supports sequential modelling of 
assignments. As an example: with a Thing (CAR), 
Assignment (WASH) might be followed by Assignment (DRY) . 
The assignment sequence is maintained by referring to WASH 
as the predecessor to DRY. 

THE TENDER ENTITY 
The client system is allowed to group together a set 
of proposals, thus allowing more complex negotiation 
behaviours to be modelled. For example, as its name 
implies. Tenders and auctions may be modelled. The system 
allows the creation of the Tender entity and notes its 
corresponding external reference. 

THE PROPOSAL ENTITY 
The system includes an important facility to model 
the existence of agents to carry out the transformations. 
As an example this might be a cleaning machine which is 
required to wash a car. This is supplied by a 'Proposal' 
entity. 

A client system wishing to identify the potential for 
an agent to impact an assignment's fulfilment will create 
a Proposal. Since in the preferred embodiment the 
Proposal has a bearing on a particular Assignment, it is 
subordinate to an Assignment in the hierarchy and in the 
preferred embodiment applies to a single Assignment only. 
Where there is no Assignment entity, a Proposal may be 
subordinate to a Thing; either way it is seen that a 
Proposal is subordinate directly or indirectly to a Thing. 

The identification of an agent by a client system is 
at no time validated by the system, but is deemed to be 
supplied by the client system as a rational and 
satisfactory identity . 
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The system provides for modelling situations where 
the potential action of the agent may often have arisen as 
a matter of negotiation. The counter-party to the agent 
in this negotiation is also identifiable by the client 
5 system. 

The system includes a facility to distinguish the 
current direction of the negotiation. 

The Proposal itself carries a rich set of features, 
sufficient and appropriate to the complexity of the 

10 environments it is intended to be capable of modelling. 

The preferred embodiment supports the following 
features within a Proposal, each being a field supporting 
input by the client system. The identity of the agent 
capable of impacting the Assignment is held in the field 

15 'Downline'. The counterparty to the agent in this 

negotiation is held in the field 'Upline'. In regard to a 
specific proposal, the Upline will have no direct impact 
upon the Assignment, The direction of the negotiation is 
implemented as a boolean flag ' DirectionGoingUp ' , which 

20 may be either true or false. 

For example, a proposal going DOWN, whereby the party 
making the proposal is the Upline and expects a reply from 
the Downline, models a request or command. Conversely, a 
proposal going UP, whereby the party making the proposal 

25 is the Downline and expects a reply from the Upline, 
models the function of volunteering. 

A proposal is something to be considered and a 
decision made on it. A proposal is therefore conveniently 
recorded using the expression Consider. Do, as will be seen 

30 below. 

As indicated above, a facility to recognise timing 
may be provided by the provision of fields to reflect the 
same. Deadlines for making a decision, and for complying 
(completing an assignment) may be included in the Proposal 
35 Entity. 
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GROUPING PROPOSALS 
By grouping proposals it is possible to extend the 
flexibility of the modelling environment to support the 
tracking of complex interactions. For example, cause and 
effect/ flow modelling, command and control and the like, 
can be grouped. This grouping is accomplished by using 
Subordinate Proposals and Sibling Proposals. 

SUBORDINATE PROPOSALS 
A further feature of the preferred system is the 
modelling of subordinate proposals. For example, in a 
factory, a Thing (CLIENTORDER) with an Assignment ( FILL) may 
require a sequence of proposals before it can be 
fulfilled. This may include the interaction of several 
people. These proposals should be grouped together. To 
achieve this the ProposallD of the Superior proposal is 
recorded in all subordinate proposals using the field 
SuperiorProposalRef ID . 

SIBLING PROPOSALS 
A further feature of the system is the grouping 
together of proposals regarding the same matter. For 
example, if in a warehouse a customer wants 1000 ball 
bearings, but there is only 800 on the shelf, then 200 
will have to be refused. All of this information will be 
stored in many proposals, but all regarding the same 
matter (i.e. the order for 1000 ball bearings). To 
achieve this grouping all sibling proposal entities store 
the original ProposallD in the field SiblingProposalRef ID . 

COMBINED PROPOSAL/ASSIGNMENT ENTITY 
As described above, the assignment entity is 
optional. The features of the assignment entity, if 
included, may be combined with a proposal entity to 
provide a combined proposal/assignment entity which has 
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the properties of both a proposal entity and an assignment 
entity . 

THE DECISION ENTITY 
5 The system records the response from the 

counter-party in regard to a corresponding proposal. This 
is the role of the Decision Entity which is subordinate to 
and can communicate with a single one of the Proposals. 
Delegated proposals are tracked by passing the Decision 

10 for a Subordinate Proposal to the Superior Proposal. An 

individual position in a negotiation is tracked by passing 
a Decision for a Sibling Proposal to all the other Sibling 
Proposals with the same SiblingProposalRef ID field. 

The response recorded by the decision entity can be: 

15 decline, accept, partially accept, or forward. Forwarding 
involves accepting the proposal but finding another agent 
actually to undertake it. The responses are recorded in 
the form Decline. Do, or Accept. Do, and so on, as 
appropriate . 



20 THE DECISION SCHEMA 

In order to derive effective meaning from the system, 
external decisions need to be recorded in a consistent, 
effective and intuitive manner. The protocol for so doing 
is implicitly provided by the creation of a logical 
25 structure, termed the decision schema. The decision 
schema comprises multiple dimensions and defines what 
types of decision may be stored. Each dimension comprises 
a set of direct fields and a set of derived fields: 

Direct fields define the types of decision that may 
30 be stored. 

Derived fields summarise the consequences or impact 

of the decision. 
It is desirable that the direct fields represent a 
set of mutually exclusive states, whereas the derived 
35 fields need not be mutually exclusive. Each field is 
assigned an index into the dimension. A decision type 
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node is then defined as a vector, comprising one index 
from each dimension. Decisions of that type have their 
quantities applied to that node, so that each node 
accumulates a summary of like decisions. 

The Decision Schema is a facility which client 
applications may use to model complex negotiations in a 
manageable and effective manner. A client application 
must, however, be clear as to its decision semantics, in 
order to make use this feature. An example of a Decision 
Schema is given below in the more detailed description of 
the preferred embodiment. 

THE DECISION CUBE 
A decision cube is built in the code in the form of a 
multidimensional array. It is used to store the 
quantities associated with each decision. Each element of 
the array should be initialised to zero. 

DESIGN PRINCIPLES FOR DECISION SCHEMAS 
Decision states (within a dimension) are exclusive. 
It is meaningless to record both an agreement to Not Do 
something, and yet that it is Done. If an agent agrees to 
NotDo something, and yet declares it Done, then it is 
regarded in the context of the system as a rogue agent. 

The decision cube does not preclude recording 
inappropriate or meaningless information. As noted above, 
it is a fundamental design principle that it is better to 
record what people claim, and then leave the external 
clients (or parties) to resolve their claims, than it is 
to try to decide the truth of a matter. Thus the system 
can record both a NotDo and a Done, and let the client 
system scan for such occurrences, and then implement 
whatever procedures necessary at that point. 

Decision states mav be partial. This requires the 
proposal to have a Quantity. For example: a proposal to 
ship 12 crates of water (Consider . Do . 12) may have the 
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response: Accept. Do. 6, Decline . Do . 4 ; leaving 2 undecided 
(Pending) . 

This also leads to a further observation: that a 
proposal using a Quantity is deemed to refer to a 
homogeneous assignment. Thus, with shipping bottles of 
water, it is assumed that the parties to the proposal are 
indifferent between two bottles of water from the same 
assignment. If partial quantities need to be 
differentiated, then they should be differentiated as 
different Things, and then renegotiated accordingly. 
Thus a crate of 20 pieces of fruit (12 Apples and 8 
Oranges) is perfectly acceptable as a Thing, provided the 
system is not expected to discriminate between Apples and 
Oranges. If it is, then it should be registered as 2 
shipments: one of Apples [Quantity 12], and the second as 
Oranges [Quantity: 8] 

OPTIONAL ENTITIES 
The entities Assignment and Tender are optional 
members of the hierarchy. Specifically a Proposal may be 
created for a Thing without requiring an Assignment or 
Tender. This facility is provided to support very simple 
scenarios, without the overhead of the unnecessary 
creation of Assigraaent and Tender entities. The hierarchy 
will always include Thing, Proposal and Decision entities. 
This heirarchical structure is illustrated in Figure 1. 

REQUIREMENTS 

The basic requirements needed to support a physical 
implementation of the system are: 

A facility to define the distinct Entities, their 

Properties, and the Values associated with 

these Properties. 
A facility to create the Entities 
A facility to have such Entities persist. 
A facility to identify particular instances of 

Entities . 
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A facility to set, edit and retrieve the Property 

Values of such Entities. 
A facility to manipulate Entities in a Hierarchy. 

THE PREFERRED EMBODIMENT 

The processes required to implement the system will 
now be described in more detail, including in particular 
the construction of the Entity hierarchy, and adding 
decisions to the hierarchy. 

The specific functions (processes) described in more 
detail below are: 

NewEntity() The facility to create a new member 

entity of the hierarchy 

RegisterEntity ( ) The facility to load an entity (into 

memory) 

LoadHierarchy ( ) The facility to load directly a full 

subordinate tree 
ApplyDecision ( ) The facility to increment the 

multidimensional data array, or cube 
ItemO The facility to retrieve a pointer 

to a member entity 
Cube: GetValue ( ) The facility to retrieve a cube's 

value at a particular node 
Notif yEvent ( ) Advising Client System of an event 

Of these functions, only two are intended to be 
accessible to clients/parties external to the system, 
namely NewEntityO and ItemO . The function 
LoadHierarchy () could be achieved by multiple applications 
of RegisterEntity ( ) but it is convenient to have it 
available as a separate function in its own right. 

The only further facility required to provide an 
effective minimal embodiment of the system is then: 



EntityPropertyValue ( ) : Retrieve the Value of a 

Property of an Entity. 
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This is a trivial process and need not: be further 
discussed. 

The utility of the system will often require a client 
application to be able to determine the state of a 
particular entity, by examining its properties. This 
function provides that facility. 

The following describes the sequencing and 
sub-processes necessary to support each of the key 
function processes highlighted above. The descriptions 
should be read in conjunction with the flowcharts in 
Figures 2 to 9 with the same title. Numeric references 
refer to these flow-charts individually. 

In the preferred embodiment of the system, the 
hierarchy consists of Things, Assignments, Tenders, 
Proposals and Decisions. Since their processing internal 
to the system is largely similar, so it is more convenient 
to regard them all as instances of a generalised Entity. 
An implementation of NewEntity ( ) therefore may be read as 

"Construct a facility, of the type: 

NewEntity (EntityTypeName) where EntityTypeName is one 
of: Thing, Assignment, Tender, Proposal, Decision." 
This allows further hierarchies to be readily developed, 
but at the cost of more sophisticated code to handle the 
distinct types . 

No^atixon : 

Numbers: 1. Numbered boxes in the 



Restrictions : 



[Thing only] 



accompanying flow-charts . 
Entities only of [this] 



type 



Exclusions : 



[Not Thing] 



Entities not of [this] 



Universal : 



[All] 



type 

Entities of all Types. 
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NewEntity () 

This is the facility to create a new member entity of 
the hierarchy and is illustrated in Figure 2 of the 
drawings. The procedure applies to all the entities 
Thing/ Assignment, Tender, Proposal, and Decision. Note 
however that Step 1 applies only to a Thing, Step 4 does 
not apply to Decision, and Step 5 applies only to 
Decision . 

Arguments: The properties of that Entity. See Entity 

Properties, below . 

1. [Thing only] A Client Reference to a Thing should be 
unique. A check is made to see if such a Client 
Reference already exists. 

la. If it does, the process is deemed to have failed. 

2. [All] Add a new record to the appropriate EntityType 
database table. Include the data from the argiaments 
to the NewEntity () call. 

3. Retrieve a unique ID (within that EntityType) for the 
new entity. 

4. Register () the new entity in memory, see below and 
Figure 3. (Create a new object in memory, of that 
type, with the appropriate data as supplied by the 
arguments in the call to the function.) 

5. Proposal: Math: AddDecision () , see below and Figure 
5. Since something has happened which could have a 
bearing on the client systems behaviour (e.g. a new 
Thing to be considered, new Assignment to be 
processed, new Tender to be negotiated, Proposal to 
be considered, or Decision to be evaluated) , so an 
EventNotif ication is sent out to the client system to 
make it aware of the event, in particular its type, 
and its ID. See Notif yEvent ( ) 

6. Notif yEvent () . Finally, an ID is returned (non-zero, 
in this embodiment), unique within the EntityType, so 
that the caller of the process may subsequently refer 
to this particular new entity, in calls to Item(), by 
its new EntityName. 
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Regis terEntity { ) 

This is the facility to load an entity (into memory), 
and is illustrated in Figure 3 of the drawings. The 
procedure also applies to all the entities Thing, 
Assignment, Tender, Proposal, and Decision. Note however 
that Steps 2, 3, 4 and 6 do not apply to a Thing, Step 
does not apply to Assignment, Step 7 does not apply to 
Decision, and Step 9 applies only to Thing. 

Arguments: The properties of that Entity. See Entity 

Properties . 

Arguments: In addition, the ID's of the Entity's 

superiors in the Hierarchy. 

1. A check is made, to discover whether this particular 
entity has already been loaded. If so, there is no 
need to load it again. Processing proceeds to Step 
11, where a Pointer to the Entity is returned, so 
that the calling function may directly reference its 
properties . 

2. [Not Thing] Item(): Get pointer to superior thing, 
see below and Figure 7. As the EntityType 'Thing', 
is the root of the Hierarchy structure, all instances 
of subordinate EntityTypes (but not a Thing itself, 
hence the exclusion) will have a superior Thing. 
This step proceeds to get a reference to the entity's 
superior Thing, by a call to Item (ThingID) . The 
ThingID is passed, along with the ID's of any other 
superior entities, in the call to the function. As a 
further consequence of the call, since Item() will 
load the Thing if not already loaded, it will load 
the full hierarchy particular to this Thing, 
including the entity which is being attempted to be 
registered. Hence this call is recursive if the 
Thing was not already loaded. Thereafter, the Thing 
being loaded, there is no further call to load the 
hierarchy, and hence to register the entity which 
originated the call to Thing. In the recursive case, 
this process again checks to see whether or not the 
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subject of the original call has now in the interim 
been loaded. 

3. [Not Thing, Not Assignment] This step calls ItemO as 
required to get pointers to further superior 
entities. A Thing has none, and as Assignment has 
only a superior Thing, so both are excluded from this 
step. These pointers will be used in Step 6, to 
allow an entity to directly reference its superiors. 
This step also provides an opportunity to ensure that 
the superiors specified in the call to this function 
are all available, and appropriate to the entity 
being registered. 

4. [Not Thing] See Step 2. Due to the recursive nature 
of the call to Item (ThingID) , this step checks to see 
whether the originally requested entity has now in 
the interim been loaded in memory. 

5. [All] In this step, a blank (uninitialised, data 
unspecified) instance of this class of entity is 
created in memory . 

6- [Not Thing] All objects other than a Thing will have 
superiors. In this step, the pointers gathered in 
Steps 2 and 3 are now assigned to appropriate 
properties in the new memory instance. In this 
particular embodiment, only the immediate superior in 
the hierarchy is assigned to the new memory entity. 
Higher superiors may then be accessed by chaining 
entity properties, e.g.: 

(Visual Basic) Proposal . Tender .Assignment 

(C++) Proposal ( ) ->Tender ( ) ->Assignment ( ) . 

7. [All] Create and link a Math Crystal. This step 
assigns the property values, passed as function 
arguments, to the appropriate Object . Properties . 
Hereafter, a client system or internal routine will 
be able to directly determine the state of the 
object, by accessing these Property Values. 

8. Assign the Entity's data. 
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9. [Proposal Only] A Proposal has a Property Quantity or 
more exactly Consider Quantity. This is the amount 
that is being offered for consideration. Where the 
field is not used or required, it may be deemed to 
have a value 1. It is therefore meaningless to 
consider the impact of decisions (how much has been 
agreed, etc.) if the original target is not known. 
This step therefore adds a Decision as a "Consider", 
with Decision parameters Action and BidWanted derived 
from the proposal properties. 

10. [Thing Only] LoadHierarchy ( ) , see below and Figure 3. 
As described earlier and elsewhere, loading a Thing 
also loads the entire hierarchy subordinate to a 
Thing. It is achieved by a call to the 
LoadHierarchy ( ) function . 

11. [All] Processing complete, the process will return a 
Pointer to the newly created memory object. 

LoadHierarchy ( ) 

This is the facility to load directly a full 
subordinate tree, and is illustrated in Figure 4. Note 
that Section I comprising Steps 1 to 5 processes the 
intermediate entity types Assignment, Tender and Proposal. 
Section II comprising Steps 6 to 9 processes the entity 
type Decision . 

Arguments: The ID (ThingID) of the Thing whose 

hierarchy is to loaded. 
The process needs to load all the Assignments, Tenders and 
Proposals associated with a Thing. It does this by 
Registering the Entities. The procedure is described 
therefore as follows . 
Section I . 

1, [Not Thing, Not Decision] The process initiates a 

sub-process for each intermediate EntityType in turn. 
The hierarchy subordinate to a Thing is being loaded, 
so Thing is redundant and excluded. Decisions are 
treated differently, later, and so here excluded. 
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2. Each EntityType's stored data (database table, in 
this embodiment) is searched for instances of this 
EntityType, with the particular Thing as their 
superior (ie: having matching ThingID) . For each 
found instance, another sub-process is initiated, 
which comprises Steps 3 and 4. 

3. For each entity instance matching the Thing, the 
entity's particular data is retrieved. 

4. The new data is passed as arguments in a 
RegisterEntity ( ) call, to load the found entity into 
memory. Control then passes back to Step 2, to 
search for the next matching instance. 

5. Once each entity type has been fully searched, 
control passes back to Step 1. If all inteirmediate 
types are complete, it passes on to Step 6. 

Section II. 

6. With the intermediate types complete, the processing 
of Decisions is now initiated. A loop is initiated, 
wherein the Decisions table is searched for decisions 
subordinate to the required Thing (matching 
•ThingID')- For each matching decision, a 
sub-process is initiated, comprising steps 7, 8 

and 9. . 

7. For a matching decision, the data is retrieved from 
the table . 

8. From the Decision's ProposalRef ID Property, and 
following a call to Item(), a pointer to the 
Decision's Superior Proposal is retrieved. 

9. Proposal: Math: AddDecisionO is executed, see below 
and Figure 5. 

10. Once all decisions matching the Thing have been 
processed, the process is complete. 

Ma1:h: AddDeclsion 

This function is called in NewEntity and 
LoadHierarchy above, and is illustrated in Figure 5 of the 
drawings . 
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Argument : None . 

1. A determination is made as to whether the decision 
source is subordinate. If it is, control passes to 
Step 2. If it is not, control passes to Step 3, 

2. The procedure sets Cube=Derived Cube. 

3. The procedure sets Cube=Normai Cube. 

4. Cube : ApplyDecision ( ) , see below and Figure 6. This 
determines the quality and type for the selected 
cube . 

5. A determination is made as to whether the Decision 
Source is Normal (see Steps 1 to 3) . If it is, 
control passes to Step 6. If it is not, control 
passes to Step 7 . 

6. Math: Add Decision to Hierarchically Superior Entity. 

7 . A determination is made as to whether the Proposal 
has a Sibling Ref. If it does, control passes to 
Step 8. If it does not, control passes to Step 9. 

8. Math: Add Decision (Sibling) to Sibling Proposal. 

9. A determination is made as to whether the Proposal is 
derived from another Proposal. If it is, control 
passes to Step 10. If it is not, control passes 

to Step 11. 

10. Math: Add Decision (Derived) to DerivedFrom Proposal. 

11. Processing complete. 

Cube : ApplyDecision ( ) 

This is the facility to increment the Decision cube's 
data which is called in Math: AddDecision above, and is 
illustrated in Figure 6. 

Arguments: Decision parameters. Decision Quantity. 

1. This process needs to translate the decision 
parameters into a node location. It therefore 
iterates through each of the decision parameters. 

2. Selecting the Decision Dimension Key for each 
parameter in turn. 

3. It translates the key into an index into that 
dimension of the cube. (See Decision Cube.) 
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4. The set of key indices thus obtained then form a 
vector into the cube, so selecting a particular node 
in the array. 

5. The node at this key is then incremented by the noted 
quantity . 

6. The derived fields in the decision schema are then 
recalculated . 

7. The process is then complete. 

ItemO 

This function is called in RegisterEntity above, and 
is the facility to retrieve a pointer to a member entity, 
and is illustrated in Figure 7. 
Argxaments: Entity Key 

1. From the Entity Key supplied, the collection of 
similar EntityTypes in memory is searched, to 
discover whether or not the Entity is already in 
memory- If it is, the process moves to Step 4, and 
returns a pointer to the entity. 

2. If the entity is not in memory, the process calls the 
ItemO function with the Entity's ThingID to get a 
pointer to the superior Thing. 

3. Since a call to Item (ThingID) always loads the full 
hierarchy, subsequent new entities will also be 
directly loaded into memory. Step 3 is not a 
process, but simply acknowledges that Thing, and its 
full hierarchy, including the required Entity, will 
be in memory at this time. 

4. The collection of the EntityTypes will now be 
searched again, and the appropriate pointer returned 
to the calling function. 

5. The process is complete. 

Math : GetMathValue . 

This is illustrated in Figure 8 of the drawings. 
This function can be called by a Client system, in order 
to find out the current status of the computer system. 
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Argument : None . 

1. A determination is made as to whether the decision 
source is subordinate. If it is, control passes to 
Step 2. If it is not, control passes to Step 3. 

2. The procedure sets Cube=Derived Cube. 

3. The procedure sets Cube=Normal Cube, 

4. Cube: GetVaiue ( ) , see below and Figure 9. The value 
is retrieved from the selected cube. 

5. Processing complete. 

C\at»e : Ge tValue ( ) 

This is the facility to retrieve the Decision cube's 
data which is called in Math: GetMathValue , and is 
illustrated in Figure 9. 

Arguments: Decision parameters. Decision Quantity. 

1. This process needs to translate the decision 

parameters into a node location. It therefore 
iterates through each of the decision parameters. 

2- Selecting the Decision Dimension Key for each 
parameter in turn. 

3. It translates the key into an index into that 
dimension of the cube. (See Decision Cube) 

4. CubeKey=Vector (DimensionKeys) . The set of key 
indices thus obtained then form a vector into the 
cube, so selecting a particular node in the array. 

5. The value of the node at this cube key is then 
retrieved . 

6. Processing complete. 

COMPUTER RESOURCES & SPECIFICATION 
While not restricted to these particular resources, 
the preferred embodiment of the system has been 
implemented on computer systems currently available. 

The prototype of the system was developed on a 
133 MHZ Pentium Notebook PC with 32Mb RAM (random access 
memory),' and a 2Gb Hard Disk, running Microsoft Windows 
NT, with Microsoft Access as the Database, and with the 
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software developed and prototyped both in Microsoft Visual 
Basic 5, and Microsoft Visual C++. 

The system was then ported to a Sun Microsystems 
Ultras, running Solaris 2.51, with a Sybase System 11 SQL 
Server database resource, and written in Unix/Ansi C++. 

ThuS/ the key requirements of the system are readily 
met by the conjunction of a typical computer system, a 
typical software coding language, and a typical database 
resource . 

SOFTWARE DESIGN 
It is readily understood that software design and 
implementation must take into account the possibility of 
function calls failing for numerous causes. Since this is 
a fundamental requirement in software engineering, which 
must be managed in any commercial implementation, the 
needs and skills appropriate to support failure will 
therefore be familiar to any software engineer skilled in 
the art. As such, they do not feature as an aspect of the 
claims of the system, such routines and techniques for 
developing robust code have been considered immaterial to 
the explicit description of the particular embodiment of 
the system. 

SCOPE OF THE PREFERRED EMBODIMENT 
The preferred embodiment implements a fixed and 
limited hierarchy, of specified types yet which is of 
sufficient power to provide a modelling and management 
facility which will cope with typical transactions and 
negotiations encompassed in the world today. 

In combination with a facility to provide agents for 
execution of processes, it then encompasses a uniform and 
general transaction facility, suitable for example 
business, domestic, military and governmental use. 

To the extent that these agents may themselves be 
computer processes, then such an environment offers a 
computerised transaction facility. Where these agents do 
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not need to refer to non-computer resources for their 
information to fulfil their transactions, then to that 
extent, the environment so described becomes an automated 
one . 

DATABASE 

For each entity type there is a corresponding 
database table. The table is given the name of the entity 
type. Thus, the existence of a 'Thing* entity leads to 
the existence of a 'Thing' table. 

THING TABLE 

The Thing Table contains references to objects 
external to the system. Each new Thing record added to 
the table has a unique ThinglD. 



Field Name 


Type 


No ties on Usage 


ThinglD 


Long 


Uniquely identifies 
a Thing 


ClientSystem 


string 


Identifies the 
Client System 


Client SystemReference 


Long 


Identifies the external 
object in the Client System 


Client Ref Description 


String 


Optional - Description 
for client convenience 
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ASSIGNMENT TABLE 

The Assignment Table contains references to processes 
to be applied to Thing entities. Each new Assignment 
record added to the table has a unique AssignmentlD. 



Fiexd Ncuue 


Type 




AssignmentlD 


Long 


Uniquely identifies an 
Ass ignment 


ThingRefID 


Long 


Thing this Assignment is 
ror 


Instigator 


String 


Supplied by client to 
identify who created 
entity 


InstigatorRef 


Long 


Supplied by client as 
external reference to 
Instigator 


PredecessorAssignmentRef ID 


Long 




Redirection 


String 


Precise nature of 
assignment 


Quantity 


Double 


How much of the 
redirection is requested 


Tho following fields can optionally be included: 


Deadline 


Date 


Date (including time) by 
which an assignment must 
be complete 


Pref erredByDate 


Date 


Date (including time) by 
which it would be 
preferred to have the 
assignment complete 
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TENDER TABLE 

The tender table contains the information which 
groups proposals- Each new Tender record added to the 
table has a unique TenderlD. 



Field Name 


Type 


Notes on Usage 


TenderlD 


Long 


Uniquely identifies a Tender 


ThingRef ID 


Long 


Thing this Tender is for 


AssignmentRef ID 


Long 


The superior Assignment in the 
hierarchy 


Instigator 


String 


Supplied by client to identify 
who created entity 


InstigatorRef 


Long 


Supplied by client as external 
reference to Instigator 


Quantity 


Double 


How much this tender relates to 
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PROPOSAL TABLE 

The Proposal contains details of the negotiation with 
an agent to perform the process. Each new Proposal record 
added to the table has a unique ProposallD. 



Field Name 


Type 


Notes on Usage 


ProposallD 


Long 


Uniquely identifies a 
Proposal 


ThingRef ID 


Long 


Thing this Proposal is for 


AssignmentRef ID 


Long 


The superior Assignment in 
the hierarchy 


TenderRefID 


Long 


The superior Tender in the 
hierarchy 


Instigator 


string 


Supplied by client to 
identify who created entity 


InstigatorRef 


Long 


Supplied by client as 
external reference to 
Instigator 


Superior ProposalRef ID 


Long 




SiblingProposalRef ID 


Long 




Upline 


string 


Who has an interest in the 
process being performed 


Downline 


string 


Who will perform the 
process 


GoingUp 


Boolean 


Who initiated the proposal 


BidWanted 


Boolean 


Does acceptance grant right 
to act 


Action 


string 


The action in regard to 
performing the process 


ConsiderQuantity 


Double 


How much of the action is 
proposed 


The following fields can optionally be Included: 


ReplyRequiredByDate 


Date 


Date by which the right to 
make a decision 
(particularly 
accept /decline) expires 


CompletionRequiredByDate 


Date 


Date by which the accepted 
quantity must be complete 
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DECISION TABLE 



Field Ncune 


Type 


No ties on Usage 


DecisionID 


Long 


Uniquely identifies a Decision 


ProposalRef ID 


Long 


Uniquely identifies a Proposal 


Instigator 


String 


Supplied by client to identify 
who created entity 


InstigatorRef 


Long 


Supplied by client as external 
reference to Instigator 


ConsiderQuantit 

y 


Double 




AnnulQuantity 


Double 


Amount of original proposal 
withdrawn 


DeclineQuantity 


Double 


A response. Amount declined from 
proposal 


AcceptQuantity 


Double 


A response. Amount accepted from 
proposal 


ForwardQuantity 


Double 


A response. Amount forwarded 
from proposal 



INSTIGATOR AND INSTIGATOR REFERENCE 
At the creation of an entity record, the client 
15 system can provide two references. One is the instigator 

of the entity creation, and the other is a meaningful 
reference to the instigator. 

These fields are available for each entity type, 
however, they are of particular significance to the 
20 creation of Thing entities. 
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DECISION SCHEMA 

The preferred embodiment implements a 
three-dimensional decision schema, with dimensions: 
Action, Authority and Resolution. 



10 



15 



20 



25 



30 



Direct fields: 

Direct fields represent the immediate description of 
the decision. The Index for each dimension in this 
embodiment is noted in brackets. 
Action: 

[0] Do: The potential exists that 

something be done . 

[1] NotDo: The potential no longer exists 

for something to be done. 

[2] Done: The claim is that something has 

in fact been done . 



Resolution: 

[0] Consider: 

[ 1 ] Annul : 

[2] Decline: 

[3] Accept: 

[4] Forward: 



Authority: 

[0] FullAuthority: 

[1] BidWanted: 



It is being put to an agent to 
(action) something . 
The (action) is no longer 
available for consideration. 
The agent declines to pursue 
the action. 

The agent accepts to pursue the 
action. 

The agent accepts the 
responsibility for the action 
but will not perform the 
action . 

Upon acceptance, the agent is 
free to pursue the action. 
There is no authority to pursue 
the action. 



Notes to clarify the above: 
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Consider - the preferred embodiment embeds this in the 

proposal. It is necessary for the logical process 
that it be part of the decision schema, but it more 
naturally represents the opportunity or quantity to 
be decided upon. 

Annul - allows the modelling of the withdrawal of an 

offer, rather than the offer being declined by the 
invitee . 

Forward - allows the modelling of the situation where a 
salesman accepts a client order/ but will not be 
fulfilling it himself. It will be fulfilled, for 
example, by the factory floor. 

BidWanted - allows a tender for a contract to be modelled, 
or an offer of tickets, where the final allocation 
will be at the discretion of the offeror, not the 
bidder . 

In the following, these are written in the order: 
Resolution .Action. Authority . 

Derived Fields : 

Given the events (decisions) it is then appropriate 
to ask what the current situation is. The creation of 
derived fields therefore allows logical processing or 
mathematics to be done on the direct fields. The 
preferred embodiment implements the following derived 
fields. Calculations to generate the derived fields are 
noted beside the field description. The Identifiers are 
taken to indicate the values or quantities associated by 
those identifiers . 

For example: (Do - NotDo - Done = Open) should be 
read as: 

If quantity required as "Do" = 12, and quantity to "NotDo" 
= 5 and quantity claimed as "Done" = 3, then the quantity 
remaining "Open" is 12 - 5 - 3 = 4, ie 12 minus 5 minus 3. 
Dimension Indices are in brackets. 
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Action 

[3] Open: (Do - Not Do - Done) Everything not 

cancelled or 
complete 

Resolution 

[5] Available: (Consider - Annul) Everything not 

withdrawn 

[6] Potential: (Available - Declined) Everything not 

declined 

[7] Pending: (Potential - Accept - Forward) 

Everything not 
decided 

Authority 

No derived fields 

Examples 

Natural examples of decisions which may be expressed in 
this schema therefore are: 

Accept. Do Accept to do something. 

Decline. Do: Decline to do something. 

Extending slightly: consider the following. 

Accept. Not Do Accept to NotDo something (eg: 

cancel an order) 
Decline .NotDo Declines to NotDo something (eg: too 

late to cancel.) 

Consider further : 

Accept, Done: Accepts that something has been 

done . 

Decline . Done : Decline to recognise that something 

has been done . 



/ 
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In the context of the system, a Do recognises the 
intent or potential to Do something, so that to Accept. Do 
for example sets up an expectation that whatever is being 
referred to will in due course be done. 

To recognise a Do is therefore to OPEN a potential. 
To CLOSE a potential, so that it can be dismissed from 
attention, one of two things must happen. Either it will 
in due course be Done or a subsequent agreement will be 
set up to NotDo that which is being referred to. 

The set [Do, NotDo, Done] therefore reflects a 
fundamental and natural set of potential intents, actions 
or claims. Given a potential that something can be done, 
so the process is initiated or OPENED as a Do; and it 
remains OPEN until either there is a matching NotDo, or it 
is Done. Whereupon it is in effect CLOSED and requires no 
further attention . 

In the example outline above the decision cube will 
have dimensions [4] [8] [2] and each element of the array 
will be initialised to zero. 

Worked Example 

This will apply 2 decisions to a Cube. The first 
will reflect asking someone to consider doing 12 of 
something (buying 12 bottles of water, for example) . The 
second will reflect the agreement of the individual to the 
proposal. The details of the nature of the transaction 
are not stored in or relevant to neither the cube nor the 
system itself- Rather, only references to the existence 
of the transaction are stored. The system manages and 
captures the complexity of the negotiation, but leaves the 
description of the transaction to the client system. 

Decision 1 : Asking someone to consider 

doing 12 of something. 

Decision Specification: Narrative /Intuitive 

description : 
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Resolution : 

Action : 
Quantity: 
Authority : 



CONSIDER Please consider the following 

proposal 
DO to do 

12 12 (of something) 

FULL with my permission to proceed, 

if you accept. 



Ciobe Vector: 

(Do =0, Consider = 0, Authority = 0): Vector = (0,0,0) 
Cube Node: 

The active node is therefore Cube[0] [0] [0] . 

Incrementing the value: the node's value is increased by 

the decision quantity. 

Cube[0] [0] [0] = Cube[0] [0] [0] + 12; 

The node Consider . Do . Full is now 12. 

Recalculation of the derived fields 

Only a typical case is shown here, for illustration. 
Available . Do , Full = Consider . Do . Full - Annul . Do . Full 
=12-0-12 



Decision 2: The invitee accepts 8 of the proposal 

Decision Type: Accept . Do . Full 

Decision Quantity: 8 

Decision Vector: [Do= 0] [Accept = 3] [ FullAuthority = 0] 
Implementation: 

Cube[0] [3] [0] = CubetO] [3] [0] + 8; 



Restricting to the Do. Full indices, the Resolution 
dimension therefore now looks as follows: 
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Resolutilon 


Quantity 


Consider 


12 


Annul 


0 


Available 


12 


Declined 


0 


Potential 


12 


Accept 


8 


Forward 


0 


Pending 


4 



For a given Action therefore, 2 key foci exist: 
How much has been Accepted; and how much is still Pending. 
The first acknowledges a commitment to something, allowing 
planning. The second, unresolved but potential 
commitments, require follow-up. 

FURTHER EMBODIMENT 
The system itself is not limited to or by the 
preferred embodiment. A more sophisticated embodiment may 
be implemented without impinging upon or materially 
reshaping the fundamentals of the system herein described. 
Some of the additions to the preferred embodiment are now 
outlined. 

ENTITY PROPERTIES 

The system may include the entity property 
EntityCreatedAT to store its TIME of creation. 

The system may include the entity property EntityVoid 
to support a facility to remove an Entity from 
consideration, in effect deleting it without actually 
removing it from the database. 

The system may include the entity property 
EntityClosed to enable a client to decide not to post any 
further transactions to that entity. Note that this 



wo 00/14663 




PCT/GB99/02906 



- 34 - 

restriction would not be controlled by the system but by 
the client system, otherwise it violates the 'Reflect 
don't Control' principle of the system. Additional 
properties which suggest internal control should be 
avoided or renamed. 

An Assignment entity may include further information 
above and beyond the simple identification of the 
transformation. For example, if a further embodiment of 
the system were to support deadline modelling, a deadline 
for the Assignment might be further included as a field in 
the Assignment entity. 

AUDIT TRAIL 

The system may include an audit trail to record the 
details of all transactions passing through the system. 

MATH IN MEMORY 
The system may include storing the complex 
calculations in memory to speed up the overall 
performance . 

ADDITION FUNCTIONS FOR CLIENT SYSTEMS 
The system may include further facilities to enrich 
the range of the functionality available to the client 
system. An example is a query facility, taking advantage 
of the fact that the storage of the embodiment is a 
database, so that client applications may implement 
queries such as: 

Assignments outstanding : Assignments not Closed, 

Pending non-zero 
Assignments overdue : Assignments not Closed, 

Created before X Date 
Agreements in place: Proposals with Downline=Y 
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DELETING ENTITIES 
The system may include a facility to delete entity 
data. In the preferred embodiment no such facility 
exists. It is a design principle that the system does not 
5 'forget* or 'lose* information. The preferred embodiment 

regards data deletion, therefore, as an internal 
housekeeping function for the user. 

Clearly, on limited capacity machines, an 
unconstrained policy of adding data without any facility 
10 for deletion will overwhelm the resources at some point. 

Therefore, a policy on deletion of data would be prudent. 
This will typically depend on the rate of accretion of new 
data, the importance of the data, the resources available, 
and policy on data storage, archiving etc. 
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CIiAIMS 

1. A transactional computer system comprising a 
plurality of entities including at least one entity of 
each of the following forms: 

a first entity (Thing entity) having the properties 
of identifying a client system and uniquely identifying an 
object in that client system; 

a second entity (Proposal entity) for defining a 
transaction, the second entity being subordinate directly 
or indirectly to a first entity and having the properties 
of modelling at least one external agent to carry out a 
transformation in relation to the first entity; and 

a third entity (Decision entity) capable of 
communicating with a second entity and having the 
properties of defining the types of decision that may be 
made, and determining the responses in relation to those 
decisions. 

2. A computer system according to claim 1, further 
comprising at least one fourth entity (Assignment entity) 
subordinate to an associated first entity, the fourth 
entity having the properties of uniquely identifying the 
associated first entity, and identifying a particular type 
of assignment or transformation to be applied to the first 
entity. 

3. A computer system according to claim 2, in which the 
fourth entity also identifies a quantity. 

4. A computer system according to claim 1, in which an 
agent modelled by the second entity includes at least two 
parties to a transaction. 

5. A computer system according to claim 4, in which the 
second entity additionally identifies the direction of 
negotiation between the parties . 
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6. A computer system according to claim 1, further 
comprising at least one second entity (Subordinate 
Proposal entity) which is subordinate to another second 
entity, and includes the property of identifying the other 
second entity to which it is subordinate. 

7. A computer system according to claim 1, further 
comprising a plurality of associated second entities 
(Sibling Proposal entities) all of which are directly 
subordinate to another second entity and each including 
the property of identifying the other second entity to 
which they are subordinate whereby the said associated 
second entities include quantities which together 
correspond to the quantity of the said another second 
entity to which they are subordinate. 

8. A computer system according to claim 1, in which the 
third entity is multidimensional and contains 
multidimensional vectors indicative of values resulting 
from an associated second entity. 

9. A computer system according to claim 8, in which at 
least one third entity is a partial entity indicating a 
partial response from a second entity. 

10. A computer system according to claim 1, further 
comprising at least one further entity (Tender entity) 
associated with a plurality of second entities and a 
single first entity, and identifying at least a quantity. 

11. A computer system according to claim 1, in which the 
system does not validate data input into the system, 

12. A computer system according to claim 1, in which the 
system provides for at least the following functions: 

(i) creation of a new entity. 
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(ii) loading a selected entity or entities into a working 
memory of the computer system, 

(iii) incrementing a multidimensional array, 

(iv) retrieving a value from an entity, and 

(v) advising the client system of an event. 

13. A transactional computer system comprising a 
plurality of entities including at least one entity of 
each of the following forms: 

a first entity (Thing entity) having the properties 
of identifying a client system and uniquely identifying an 
object in that client system; 

a second entity (combined Proposal/Assignment 
entity) for defining a transaction, the second entity 
being subordinate to a first entity and having the 
properties of (i) modelling at least one external agent to 
carry out a transformation in relation to the first 
entity, and (ii) uniquely identifying the associated first 
entity, and identifying a particular type of assignment or 
transformation to be applied to the first entity; and 

a third entity (Decision entity) capable of 
communicating with a second entity and having the 
properties of defining the types of decision that may be 
made, and determining the responses in relation to those 
decisions, 

14. A transactional computer system comprising: 
first means defining a first entity (Thing entity) 

having the properties of identifying a client system and 
uniquely identifying an object in that client system; 

second means defining a second entity (Proposal 
entity) for defining a transaction, the second entity 
being subordinate directly or indirectly to a first entity 
and having the properties of modelling at least one 
external agent to carry out a transformation in relation 
to the first entity; and 
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third means defining a third entity {Decision 
entity) capable of communicating with means defining a 
second entity and having the properties of defining the 
types of decision that may be made, and determining the 
responses in relation to those decisions. 

15. A computer system according to claim 14, further 
comprising at least one fourth means defining a fourth 
entity (Assignment entity) subordinate to an associated 
first entity, the fourth entity having the properties of 
uniquely identifying the associated first entity, and 
identifying a particular type of assignment or 
transformation to be applied to the first entity. 

16. A computer system according to claim 15, in which 
the fourth entity also identifies a quantity. 

17. A computer system according to claim 14, in which an 
agent modelled by means defining the second entity 
includes at least two parties to a transaction. 

18. A computer system according to claim 17, in which 
the means defining a second entity additionally identifies 
the direction of negotiation between the parties . 

19. A computer system according to claim 14, further 
comprising at least one means defining a second entity 
(Subordinate Proposal entity) which is subordinate to 
another second entity, and includes the property of 
identifying the other second entity to which it is 
subordinate . 

20. A computer system according to claim 14, further 
comprising a plurality of means defining associated second 
entities (Sibling Proposal entities) all of which are 
directly subordinate to another second entity and each 
including the property of identifying the other second 
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entity to which they are subordinate whereby the said 
associated second entities include quantities which 
together correspond to the quantity of the said another 
second entity to which they are subordinate. 

21. A computer system according to claim 14, in which 
the third entity is multidimensional and contains 
multidimensional vectors indicative of values resulting 
from an associated second entity. 

22. A computer system according to claim 21, in which at 
least one third entity is a partial entity indicating a 
partial response from a second entity. 

23. A computer system according to claim 14, further 
comprising at least one means defining a further entity 
(Tender entity) associated with a plurality of second 
entities and a single first entity, and identifying at 
least a quantity. 

24. A computer system according to claim 14, in which 
the system does not validate data input into the system. 

25. A computer system according to claim 14, in which 
the system provides for at least the following functions: 

(i) creation of a new entity, 

(ii) loading a selected entity or entities into a working 
memory of the computer system, 

(iii) incrementing a multidimensional array, 

(iv) retrieving a value from an entity, and 

(v) advising the client system of an event. 

26. A transactional computer system comprising: 
first. means defining a first entity (Thing entity) 

having the properties of identifying a client system and 
uniquely identifying an object in that client system; 
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second means defining a second entity (coxt±>ined 
Proposal/Assignment entity) for defining a transaction, 
the second entity being subordinate to a first entity and 
having the properties of (i) modelling at least one 
external agent to carry out a transformation in relation 
to the first entity, and (ii) uniquely identifying the 
associated first entity, and identifying a particular type 
of assignment or transformation to be applied to the first 
entity; and 

third means defining a third entity (Decision 
entity) capable of communicating with measn defining a 
second entity and having the properties of defining the 
types of decision that may be made, and determining the 
responses in relation to those decisions. 

27. A computer system arranged to operate in accordance 
with a protocol, wherein the protocol causes the computer 
to generate a plurality of entities including at least one 
entity of each of the following forms: 

a first entity (Thing entity) having the properties 
of identifying a client system and uniquely identifying an 
object in that client system; 

a second entity (Proposal entity) for defining a 
transaction, the second entity being subordinate directly 
or indirectly to a first entity and having the properties 
of modelling at least one external agent to carry out a 
transformation in relation to the first entity; and 

a third entity (Decision entity) capable of 
communicating with a second entity and having the 
properties of defining the types of decision that may be 
made, and determining the responses in relation to those 
decisions . 
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28. A method of programming a computer, comprising the 
steps of: 

generating a first entity (Thing entity) having the 
properties of identifying a client system and uniquely 
identifying an object in that client systems- 
generating a second entity (Proposal entity) for 
defining a transaction, the second entity being 
subordinate directly or indirectly to a first entity and 
having the properties of modelling at least one external 
agent to carry out a transformation in relation to the 
first entity; and 

generating a third entity (Decision entity) capable 
of communicating with a second entity and having the 
properties of defining the types of decision that may be 
made/ and determining the responses in relation to those 
decisions . 

29. A computer program product directly loadable into 
the internal memory of a digital computer, and comprising 
software code portions for causing the computer to become 
a computer in accordance with claim 1 when the product is 
run on a computer, 

30. A computer program product directly loadable into 
the internal memory of a digital computer, and comprising 
software code portions for causing the computer to become 
a computer in accordance with claim 14 when the product is 
run on a computer. 

31. A computer program product directly loadable into 
the internal memory of a digital computer, and comprising 
software code portions for causing the computer to become 
a computer in accordance with claim 27 when the product is 
run on a computer. 
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I. Basis of the report 

1 This report has been drawn on the basis of (substitute sheets which have been furnished to the receiving Office in 
response to an invitation under Article 14 are referred to in this report as "originally filed" and are not annexed to 
the report since they do not contain amendments.): 
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1 -35 as originally filed 
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as originally filed 



Drawings, sheets: 

1/9-9/9 



as originally filed 



2. The amendments have resulted in the cancellation of: 

□ the description, pages: 

□ the claims, Nos.: 

□ the drawings, sheets: 



□ This report has been established as if (some of) the amendments had not been made, since they have been 
considered to go beyond the disclosure as filed (Rule 70.2(c)): 



4. Additional observations, if necessary: 
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1. Statement 



Novelty (N) 
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Inventive step (IS) 
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Claims 


1-31 




No: 


Claims 




Industrial applicability (lA) 
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Claims 
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2, Citations and explanations 
see separate sheet 



INTERNATIONAL PRELIMINARY International application No. PCT/GB99/02906 
EXAMINATION REPORT - SEPARATE SHEET 



ad section V: 

1 . The present invention solves the technical problem of how to realize in a computer 
a uniform and general transaction model which a user can adapt to many 
specific types of transactions. 

None of the available documents is concerned with said problem and anticipates 
or suggests the hierarchy of model entities as defined in independent Claims 1 . 
13, 14, 26, 27 and 28 to 31, respectively. 

While the computer system described in the first document of the International 
Search Report builds multiple models of complex business transactions, said 
multiple models ( an information model, an information flow model, a process 
description language diagram and a functional decomposition diagram) each give 
a different perspective of the same design of an information management system 
of an organization. That known system stores ordered sets of references to the 
design data, such as entities. 

2. Dependent Claims 2 to 12 and 15 to 25 specify preferred embodiments of the 
subject-matter of the independent claim to which they refer respectively. 
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ad section V: 

1 . The present invention solves the technical problem of how to realize in a computer 
a uniform and general transaction model which a user can adapt to many 
specific types of transactions. 

None of the available documents is concerned with said problem and anticipates 
or suggests the hierarchy of model entities as defined in independent Claims 1 , 
13, 14, 26, 27 and 28 to 31 , respectively. 

While the computer system described in the first document of the International 
Search Report builds multiple models of complex business transactions, said 
multiple models ( an information model, an information flow model, a process 
description language diagram and a functional decomposition diagram) each give 
a different perspective of the same design of an information management system 
of an organization. That known system stores ordered sets of references to the 
design data, such as entities. 

2. Dependent Claims 2 to 12 and 15 to 25 specify preferred embodiments of the 
subject-matter of the independent claim to which they refer respectively. 



Form PCT/Separate Sheet/409 (Sheet 1) (EPO-April 1997) 



[i|^::nt cooperation treaty 

PCT 



INTERNATIONAL SEARCH REPORT 



(PCT Article 18 and Rules 43 and 44) 



Applicant's or agent's file reference 
39713/RCA 


FOR FURTHER Notification of Transmittal of International Search Report 

{Form PCT/ISA/220) as well as, where applicable, item 5 below. 

ACTION 


International application No. 
PCT/GB 99/02906 


International filing date (day/month/year) 

03/09/1999 


(Earliest) Priority Date (day/month/year) 

04/09/1998 


Applicant 

BALAENA LIMITED et al . 



This International Search Report has been prepared by this International Searching Authority and is transmitted to the applicant 
according to Article 18. A copy is being transmitted to the International Bureau. 



This International Search Report consists of a total of 3 sheets. 

[X] it is also accompanied by a copy of each prior art document cited in this report. 



1 . Basis of the report 

a. With regard to the language, the international search was carried out on the basis of the international application in the 
language in which it was filed, unless otherwise indicated under this item. 

I I the international search was carried out on the basis of a translation of the international application furnished to this 
Authority (Rule 23.1(b)). 

b. With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the international search 
was carried out on the basis of the sequence listing : 

I I contained in the international application in written form. 

I I filed together with the international application in computer readable form. 

I I furnished subsequently to this Authority in written form. 

I I furnished subsequently to this Authority in computer readble form. 

I I the statement that the subsequently furnished written sequence listing does not go beyond the disclosure in the 
international application as filed has been furnished. 

I I the statement that the information recorded in computer readable form is identical to the written sequence listing has been 
furnished 

2. Q Certain claims were found unsearchable (See Box I). 

3. Q Unity of invention is lacking (see Box II). 



4. With regard to the title, 

[X] the text is approved as submitted by the applicant. 

I I the text has been established by this Authority to read as follows: 



5. With regard to the abstract, 

pr| the text is approved as submitted by the applicant, 
the text has been established, according to Rule 3J 

within one month from the date of mailing of this international search report, submit comments to this Authority 
The figure of the drawings to be published with the abstract is Figure No. 1 



j — I the text has been established, according to Rule 38.2(b), by this Authority as it appears in Box III. The applicant may, 



pr| as suggested by the applicant. None of the figures. 

I I because the applicant failed to suggest a figure. 

I I because this figure better characterizes the invention. 



Form PCT/lSA/210 (first sheet) (July 1998) 



INTERN^ONAL SEARCH REPORT i 



final Application No 

!b 99/02906 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 G06F17/60 G06F17/30 



Acco rding to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 G06F 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



/ 



us 5 249 300 A (BACHMAN CHARLES W ET AL) 
28 September 1993 (1993-09-28) 
abstract; figure 1 

column 22, line 50 -column 24, line 31 
column 3, line 35 - line 45 

US 5 390 330 A (TALATI KIRIT K) 
14 February 1995 (1995-02-14) 
abstract; figure 2 
column 2, line 6 -column 4, line 36 

US 5 638 539 A (GOTI JUAN C) 
10 June 1997 (1997-06-10) 
abstract; figures 3,8 
column 1, line 53 - line 62 

-/— 



1,13,14, 
26-31 



1,13,14, 
26-31 



1,13,14, 
26-31 



Further documents are listed In the continuation of box C. 



Patent family members are listed in annex. 



° Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
"E" eariier document but published on or after the international 

filing date 

"L" document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



'T" later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underiying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

"&" document member of the same patent family 



Date of the actual completion of the international search 



28 January 2000 



Date of mailing of the international search report 



04/02/2000 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL -2280 HVRijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



van der Wei den, A 



Fomn PCT/tSA/210 (second sheet) (July 1992) 



page 1 of 2 



INTERN^ONAL SEARCH REPORT 



# 



Int^^ij^^al Application No 



99/02906 



C.(Contlnuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category " 



t- 



Citation of document, with indication, where appropnate, of the relevant passages 



Relevant to claim No. 



A ^ 



GB 2 271 002 A (DIGITAL EQUIPMENT INT) 
30 March 1994 (1994-03-30) 
abstract; figure 3 
page 1 -page 9 

WO 94 19742 A (MASSACHUSETTS INST 
TECHNOLOGY ;MALONE THOMAS W (US); CROWSTON 
KEVI) 1 September 1994 (1994-09-01) 
abstract; claim 1; figures 6,14 



1,13,14, 
26-31 



1,13,14, 
26-31 



Form PCT/ISA/210 (continuation of second sheet) (July 1992) 



page 2 of 2 



INTER 

Infoi 



NAT K 

m 



JIONAL SEARCH REPORT 

on patent family members 



In^^^^nal Application No 

pSRb 99/02906 



Patent document 




Publication 




Patent family 




Publication 


cited in search report 




date 




member(s) 




date 


US 5249300 


A 


28-09-1993 


CA 


2081546 


A 


28-10-1991 








EP 


0531319 


A 


17-03-1993 








JP 


6501576 


T 


17-02-1994 








WO 


9117494 


A 


14-11-1991 


US 5390330 


A 


14-02-1995 


AU 


677835 


B 


08-05-1997 








AU 


6392094 


A 


29-08-1994 








CA 


2155865 


A 


18-08-1994 








EP 


0686285 


A 


13-12-1995 








WO 


9418629 


A 


18-08-1994 








US 


5677997 


A 


14-10-1997 








US 


5915115 


A 


22-06-1999 








US 


5999942 


A 


07-12-1999 


US 5638539 


A 


10-06-1997 


US 


5875330 


A 


23-02-1999 


GB 2271002 


A 


30-03-1994 


NONE 






WO 9419742 


A 


01-09-1994 


AT 


172308 


T 


15-10-1998 








AU 


6354694 


A 


14-09-1994 








CA 


2156917 


A 


01-09-1994 








DE 


69413956 


D 


19-11-1998 








DE 


69413956 


T 


02-06-1999 








EP 


0692113 


A 


17-01-1996 








US 


5819270 


A 


06-10-1998 



\ 



Form PCT/ISA/210 (patent family annex) (July 1992) 



PCT/GB 99/02906 

F ENT COOPERATION i REA 



From the INTERNATIONAL BUREAU 



PCT 


To: 


NOTIFICATION OF ELECTION 


Assistant Commissioner for Patents 




United States Patent and Trademark 


(PCT Rule 61.2) 


Office 




Box PCT 




wasningion, u.u.zuzoi 




ETATS-UNIS D'AMERIQUE 


Date of mailing (day/month/year) 


in its capacity as elected Office 


22 May 2000 (22.05.00) 




International application No. 


Applicant's or agent's file reference 


PCT/GB 99/02906 


39713/RCA 


International filing date {day/month/year) 


Priority date (day/month/year) 


03 September 1999 (03.09.99) 


04 September 1998 (04.09.98) 


Applicant 




MATHER, Andrew, Harvey 




1. The designated Office is hereby notified of its election made; 


in the demand filed with the International Preliminary Examining Authority on: 


04 April 2000 (04.04.00) 


I I in a notice effecting later election filed with the International Bureau on: 


2. The election [x\ was 




1 I was not 




made before the expiration of 1 9 months from the priority date or, where Rule 32 applies, within the time limit under 


Rule 32.2(b). 






Authcrired officer 


The International Bureau of WlPO 




34, chemin des Colombettes 


Pascal Piriou 


1211 Geneva 20, Switzerland 




Facsimile No.: (41-22) 740.14.35 


Teleohone No.: (41-22) 338.83.38 


Form PCT/IB/331 (July 1992) 


GB9902905 



